1. Field of the Invention
The invention relates generally to techniques for maintaining records of changes made in persistent data by data processing systems and more particularly to techniques for maintaining records of changes in persistent data that defines the configuration of the data processing system.
2. Description of Related Art
The task of a large class of applications that run on computer systems is to make changes in persistent data, that is, data that is not lost when the program that is manipulating it ceases execution. Many such programs have provisions for tracking the changes made in the persistent data. A simple example of these provisions is the change tracking arrangements provided by most word processors, which can be used to provide a history of the changes made to a document over time. More complex examples are the logging facilities provided for large database systems, which record every transaction performed in the database system.
The main reason for the existence of logging facilities in large database systems is being able to recover from system failure. If there is a log, one can use the log to redo transactions that were lost because of the failure. Of course, people quickly found other uses for the log. If it could be used to redo transactions, it could also be used to replicate transactions; further, since the log recorded every transaction in the system, it could be analyzed both to see whether the database system's efficiency could be improved and to see how outside events were reflected in the database system. For example, one could examine the log to see whether the number of a certain kind of transaction increased during an advertising campaign. Finally, because the log recorded every transaction, it could be used to make an audit trail, that is, to determine what changes were made as a result of a transaction, who made them, and when they were made.
The chief difficulty with using traditional database system log files to analyze transactions or make audit trails was that the log files recorded changes at the level of the physical blocks used to store data in the database system. While the information was all there, getting it was a tedious and error prone process. Among the techniques used to simplify getting information out of the log files were producing a printable version of the log file in which the information was in printable form and making logical versions of the log. The printable version was of course much more easily read by humans than the original physical log file and could also be searched using standard text search tools. In the logical version, the transaction was described in terms of the query language commands which brought it about. Again, this made it more readable by humans. A further advantage of the logical version of the log was that it could be made into a database table and queried to obtain information from it. An example of such a logical version of the log is the one provided by the LogMiner facility in the Oracle 9i™ data base management system manufactured by Oracle Corporation, Redwood City, Calif.
While printable log files and logical log files are much easier to use than physical logs, getting from a printable log file or a logical log file to an audit trail is still difficult. One reason is the sheer mass of information in the log file; locating the information needed to make a particular audit trail in the log file still requires a precise knowledge of what text is to be searched for in the printable log file or what tables are involved in the transactions in the logical log file in order to make queries that will return the desired information. Another reason is that the information in the log file is still only a starting point. In the LogMiner facility, for example, there is no easy way to relate a transaction to the person responsible for it. The transaction in both the physical log file and the logical log file is identified by a transaction number, and information outside the logical log file is needed to determine what person is responsible for the transaction. Similarly, there is no easy way to determine when a transaction was performed. Transactions are ordered in the physical and logical log files by sequence numbers and there is nothing within the physical or logical log file which provides a mapping from sequence numbers to time.
While making audit trails remains hard, the need for them is increasing. That is particularly the case for process control systems that are used in the pharmaceutical industry. There, 21 CFR Part 11 has extended the audit trail requirements for such process control systems to require audit trails of changes in the configuration of the process control system. What is needed is a way of fulfilling these new requirements that is less cumbersome than the techniques described above for extracting such information from physical log files, printable log files, or logical log files. It is thus an object of the invention disclosed herein to simplify the process of making audit trails of configuration changes.